How to strengthen security on login portals

If you are an application developer or security analyst, you likely spend a lot of time thinking about your customers’ security. IT operations teams have found many ways to help secure login portals by implementing dual authentication and Single-Sign-On (SSO) portals. Many IT organizations have learned to use SSO and Two Factor Authentication (2FA) to help secure their codebase and employee data. This method is great, assuming that all users are compliant with 2FA. However, this can get in the way of accessibility for shared accounts with family and friends on streaming applications and games. For instance, a lot of “boosted” players regularly share accounts with more skilled gamers, family members, or friends. “Smurfing” by playing on lower-ranked or new accounts is also a very common practice. 2FA is cumbersome for sharing streaming media, such as with Netflix if you have a family account with individual profiles across devices.

DevOps teams today are faced with compliance challenges when dealing with the Children’s Online Privacy Protection Act (COPPA) and General Data Protection Regulation (GDPR), on top of standard security concerns. While 2FA is a step in the right direction and allows for additional security, it puts the onus on the user to manage their data securely. There are other additional steps DevSecOps teams can do on the IT infrastructure side to prevent a data breach.

Common account exploits and how to secure them

Hacking via API requests

One common exploit occurs on registration and login portals, where hackers can access customer information via API requests. On websites that do not properly secure that data, hackers can send a request with any user number and get the information for that user. If that works, all they need to do is send that same scripted request in a loop for user ID 0, 1, 2, 3, 4, etc…iterated up to whatever the maximum number is, and then download all customers’ data. This is a common exploit that affects any login portal to download entire databases of customer information.

How this exploit works

Hackers inspect network data and see that they have made an API request to a web service address. They can see what the endpoint (URL) was, the service name, and what data was sent to it. If the data sent to the web service were fairly simple, like a user ID, then hackers can just call it with any user ID.

Service endpoints can come from a variety of different places, including phone apps, desktop web addresses and client desktop applications. Regardless of where the user interacts with the endpoint on a SaaS login portal, the application will be running on a web service endpoint, which could look something like this:

“My.com/Myservice/FunctionName/parameters?Param=value”

Hackers may find: “My.com/Myservice/GetAccountInfo/?UserId=123” and if it returns data with just that, then they could run a script that calls the service (in a loop) with every UserID.

Realistically, the website should have a user-specific key that legitimate users get when logging in. Users would call it with: “My.com/Myservice/GetAccountInfo/?UserId=123&UserKey=8926348768732”
If that UserKey is missing or isn't what the web service backend expects, the service would just return an error code.

Another common exploit occurs when IT teams implement a hard-coded admin backdoor that they think is secure, but isn’t. Hackers can brute force it with a script and get access to everything in that codebase. An example could look like this: “My.com/Myservice/GetAccountInfo/?UserId=69420&UserKey=1337123”

Most web services allow only three to five tries a day, but hackers run brute force scripts from multiple locations or IP addresses. Within a few weeks (sometimes a few months), they can guess the login. Cycling through a few passwords every month can help, but ultimately you want to monitor for potential threats.

How to secure this exploit

Each user account should be provided with its own API key to call the get user account function. The website would use the user login to retrieve the API key, which is in turn used for accessing the account info for that user. API keys should generally be unique for every login location and should expire sometime after login. The issue the developer is solving is to avoid the user’s password from being sent across the internet more than it needs to be or stored in a cookie on the user’s computer. Cookies can be accessed anywhere by any company that collects them.

Logging and tracing can be used to detect whether an unauthorized user is trying to access an API key or if there are similar requests from different locations attempting to access user information. For example, this could be checked via this landspeed violation lab, also referred to as a ‘superman’ scenario or ‘impossible travel’ login.

When a user first logs in, they download a public key (stored in a cookie) provided by the game’s account management system. This public API key is used for accessing user account data, such as changing passwords, updating payment info, microtransactions, etc.

If developers are logging every API request, they can see that one address requested account data for multiple accounts and flag it. Moreover, user logins and data should be stored separately from the game server. Those who can hack the game server can also access the user login data.

How to respond to incidents with playbooks

The application of standard operating procedures (SOPs) to modern security operations is becoming more prevalent. The importance of SOPs grows as the efficiency of SecOps becomes more critical in today’s unpredictable and fast-growing threat landscape. By relying on well-laid-out SOPs, security response teams can follow an optimized path to SecOps completion, allowing analysts and other security practitioners to save the time necessary to cope with the growing influx of alerts. Security Orchestration, Automation, and Response (SOAR) platforms help DevSecOps teams build their SOPs in a graphical and actionable workflow, called “playbooks”, which can easily integrate, orchestrate and automate all your security stack.

Playbook for password spray attacks

One playbook example uses a password spray attack, where common passwords are attempted to authorize login for a given set of users, from an external IP. The security operations center (SOC) analysts can block the source user if the source IP is malicious or if the user had too many login attempts. To learn more about setting password policy, check out this help page.

Playbook for compromised internal hosts

Another playbook we suggest is for compromised internal hosts in a hybrid environment, detected through events from AWS:

1. If the events from AWS contain suspicious events, an additional query will be done in order to collect more information and give the SOC analysts the ability to quarantine the infected host.

2. If the events from AWS contain multiple login attempts, this playbook runs a nested playbook to reset the password in Active Directory.

To learn more about threat hunting in hybrid cloud environments, check out this article.

To request a demo of these playbooks, click here.

Conclusion

We all do our best when it comes to securing our code and user data. However, data breaches and hacks occur from practitioners’ lack of understanding of exploits. It is important to stay up to date and utilize modern data protection methods. If all else fails, observability is key. Sumo Logic helps operations teams by using AI-based parsing utilities so you can more quickly draw your attention to anomalies and identified threats. Sumo Logic Cloud SOAR automates your incident response to boost the efficiency of the entire team. It connects disparate tools to automate incident response, leaving time-consuming tasks behind. Playbooks highlight appropriate courses of action, reducing the time needed to remediate incidents.